1. The Field of the Invention
The field of the present invention is computer software driver development. The present invention relates to tools, software frameworks, conventions, etc. to simplify code generation of drivers and provide standardized access points. More specifically, the present invention is directed to methods and computer program products for managing buffers used by multiple entities, such as interconnected software drivers, so that a minimum amount of inter-buffer data transfer occurs between entities during processing by software drivers running in a relatively unprotected operating system mode.
2. The Prior State of the Art
When multiple components process a stream or amount of data, they will typically place a quantity of data, such as a frame, into a buffer, process the data, and copy the manipulated data into another buffer corresponding to another processing component. If there are multiple independent processing components, the sheer volume of data transfers between buffers can impact processor performance to the degree that it may inhibit the actual processing of the data itself in a timely fashion.
While this problem may occur with any type of data processing between different components, it is particularly acute with the media data found in multimedia applications. This is due, in part, to the large quantities information generated that is in many instances tied to a time frame to effectively produce a veritable xe2x80x9cstreamxe2x80x9d of continuous data for processing. Such media information may come from a live feed over a network, phone line, digitizing hardware, etc. or some other source such as a file and usually must be processed in xe2x80x9creal timexe2x80x9d so as to be coherent to a viewer or listener.
In a multimedia environment, when processing a stream of media data, the processor performance impact due to data transfers between different buffers creates a latency problem that reduces overall media processing and rendering performance of a hardware/software system. A latency problem may be so bad as to limit what a particular system may handle in terms of multimedia capabilities. The situation becomes exacerbated on general purpose computer systems such as a processor running Windows NT(trademark) by Microsoft(copyright) because of the already existing demands on the processor. Reducing latency problems opens many opportunities to provide low-cost multimedia applications that would otherwise be unavailable. If latency is sufficiently reduced by increased system processing efficiency and other means, a general purpose computer system will be able to run multimedia applications that were previously not possible.
Another problem associated with multiple buffers corresponding to multiple processing components is the amount of system resources that may be used and therefore unavailable to other applications. In other words, if each processing component has its own buffer taken from system resources such as system memory, system resources become more scarce thereby causing inefficiencies that may result in degraded system performance.
Shared memory between processes and components attempts to address the resource allocation problem and allow shared buffers. A shared memory facility normally occurs at an operating system xe2x80x9cuser modexe2x80x9d that has significant safety overhead to assure only authorized applications used designated address spaces in system memory and where user written applications are run. The safety mechanisms are for assuring that one application or process will not impact another application.
In a multimedia environment, it is advantageous to interconnect software drivers so that processing may occur in software drivers that run in an operating system mode with a much higher run priority and little security protection to allow access to actual hardware that the drivers, in many instances, directly manipulate. Many applications are benefited by running in this looser and more performance-oriented mode, generally referred throughout, in Windows NT terminology, as xe2x80x9ckernel mode.xe2x80x9d Other robust operating systems will have a functionally equivalent mode.
One prime example of a program currently incapable of easily using kernel mode drivers, used throughout this application, comprises graph building functionality that allows a user to select and connect together different processing blocks, called filters, to successively manipulate a stream of multimedia data. The data typically is a series of samples representing sound or video and the processing blocks may include decompression processing for compressed data, special effects processing, CODEC functionality, rendering the data into analog signals, etc.
Such filters typically are located in user mode so that the graph builder portion of the program may interconnect and control their operation and be responsive to user input and rearrangement of processing blocks. Because of the consistent stream nature of multimedia data and the generation of large quantities of data, performance is a critical issue. In a general purpose operating system, system performance caused by repeatedly passing/switching back and forth between user mode and kernel mode can be so degraded as to prohibit certain multimedia applications as mentioned previously.
Furthermore, the processing blocks will many times have hardware associated therewith requiring multiple transitions between user mode and kernel mode components. Such transitions comprise another form of overhead that takes away from the overall multimedia processing system performance. When making transitions between user mode and kernel mode, there may also be overhead associated with copying the data between different buffers that would be unnecessary if the processing remained in kernel mode.
What is needed is a mechanism for creating a shared buffer and communicating its existence between independent software drivers so that data may be processed in the same buffer by two or more components in an interconnected software driver environment. It would be advantageous for such a mechanism to also communicate buffer requirements of a software driver to allow a third party agent such as a graph builder dynamically interconnect different software drivers to accomplish a certain media stream processing sequence.
It is an object of the present invention to separate the buffers holding data for processing from a series of distinct processing components so that each processing component can sequentially process the data without necessarily transferring the data to a buffer associated with the processing component.
It is an object of the present invention to reduce the number of inter buffer data transfers associated with the processing of data by a plurality of separate and distinct processing components.
It is another object of the present invention to reduce latency effects in multimedia system.
It is a further object of the present invention to allow general purpose computing systems with the ability to handle data intensive multimedia applications with greater effectiveness than heretofore possible.
It is yet another object of the present invention reduce the need for system resources in processing applications having multiple processing components by providing a standardized way to communicate buffering needs and buffer allocation abilities of a particular component.
It is an object of the present invention to allow a third party component to create available buffer allocation mechanisms as part of interconnecting separate components as determined by first querying and receiving the requirements of all components prior to making the interconnections.
Additional objects and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the invention. The objects and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims.
To achieve the foregoing objects, and in accordance with the invention as embodied and broadly described herein a method and computer program product for reducing inter-buffer data transfers between separate processing components is provided. A processing component, such as a kernel mode driver, will have certain buffering requirements such as byte alignment or frame processing sizes that it can support as well as buffer creation and management capabilities in order to provide buffers according to the requirements. A buffer may then be created with some reference (e.g., reference to the buffer allocator or the buffer itself) being given to another processing component earlier in the processing chain. If no new buffer is required, a processing component will simply process the data in the existing buffer (e.g., in place or in situ processing) regardless of location or by what entity created.
A processing component will, therefore, only transfer data to a new buffer when one is necessary for the next processing component in the chain. Since different combinations of chains are possible with interconnected processing components, some occasions will require a buffer allocator and others will not depending on the particular processing component arrangement. Processing components should therefor support the ability to communicate buffer requirements and capabilities to a third party component that will be responsible for making the interconnections between processing components and assuring that buffering is done properly between processing components.
One embodiment of the present invention occurs as part of connecting kernel mode drivers in a standardized fashion. A given driver or filter will support and define pin factories that are used to instantiate connection pin instances that may be interconnected to connection pin instances on other drivers to allow processing messages to be consecutively processed in kernel mode by the drivers without necessary resort to a user mode agent.
A third party agent desiring to connect compliant drivers will query the drivers of their capabilities through reference to connection pin factories. Such capabilities include what kinds of connection pin instances may be instantiated, including their relevant characteristics, such as type of data handled, data formats, transfer rates, medium or mode of transfer, input or output nature of a connection pin instance, etc. Also queried will be the data buffering requirements and capabilities for allocating buffers available at each connection pin factory.
Once a third party agent, typically running in user mode, has queried the capabilities of one or more compliant drivers, the agent will determine the best connection characteristics for xe2x80x9cchainingxe2x80x9d multiple drivers together so that data may be optimally processed between them. This determination step occurs after all driver capabilities have been queried so that the optimal connection criteria may be selected.
For each connection pin instance, the third party agent will also determine whether a buffer allocator need be created on a particular pin instance. Again, this is done after having queried all the different filters and pin factories prior to making any interconnections.
The third party agent then interconnects the drivers by creating the necessary connection pin instances utilizing the pin factories found on the filters. The agent will specify a data format and a connection format as part of the connection pin instance creation. Furthermore, if a buffer allocator is needed for a particular pin instance, the third party agent will create the allocator using the the handle of the connection pin instance as a parent. In an exemplary embodiment implemented under the NT operating system, an actual connection pin instance is created by a create I/O operation that returns a handle to a xe2x80x9cfile.xe2x80x9d The create I/O request will contain the driver instance handle and reference to a data structure indicating data format and connection format for the connection pin instance.
Furthermore, reference to previously created connection pin instances (e.g., input pin instances or IRP xe2x80x9csinkxe2x80x9d pins) will be specified in requests for creating other connection pins (e.g., output pin instances or IRP xe2x80x9csourcexe2x80x9d pins) in order to effectuate a connection between connection pin instances. After a source pin instance is created using a reference to an input pin instance having a buffer allocator, indication is made with the source pin instance of the buffer allocator so that data may be transmitted into the new buffer from the existing buffer. If no reference is indicated, the source pin will leave the data in the existing data after processing.
In order to create a compliant driver, a driver developer will support certain standard facilities to allow a user mode agent to query capabilities and make interconnections between drivers. In one embodiment built on the Windows NT operating system, this is achieved by use of xe2x80x9csetsxe2x80x9d (i.e., property, method, and event sets) that implement the desired functionality.
A set is logically defined as having a GUID (globally unique identifier) to identify the set as a whole and a RUID (relatively unique identifier, e.g., relative within the set itself) for each element of functionality within the set. Each set is associated with only one or two IOCTLs (IO Controls), and an IOCTL combined with a set specification controls all interaction with the driver.
As currently embodied, three types of sets are utilized, namely, property sets, method sets, and event sets. Property sets are used for managing values or settings within the driver, such as sound volume, transfer rate, etc., and use a single IOCTL with a flag indicating whether the call is getting a property value and or setting a property value. Method sets are used for managing the operations that a driver may perform, such as allocating memory, flushing buffers, etc., and uses a single IOCTL to call the specified method. Event sets are used for managing events associated with driver processing, such as device change notification, data starvation notification, etc., and uses two IOCTLs, one for enabling a specified event and one for disabling a specified event.
To use a set, an I/O control operation is initiated using the specified IOCTL and reference to a data structure having the set GUID, RUID, and other necessary data. For example, setting a volume property on a sound card driver would entail an I/O control operation using a set property IOCTL, specifying the appropriate GUID for the property set having the volume setting, indicating the specific RUID within that set indicates the volume property, and containing the new volume setting value.
To query the sets supported, a null GUID is used along with a query flag on a specified IOCTL for a particular set type (e.g., property set IOCTL, method IOCTL, or event enable IOCTL) and a list of set GUIDs supported will be returned. To query supported properties, methods, or events within a given set, the set GUID, set type IOCTL, and a query flag are used with the operation returning a list of supported RUIDs.
By using the generic set mechanism, a minimum of functionality may be implemented to support a compliant driver but still allow unlimited extensibility. A set may be defined in a written specification that can be independently coded by a multitude of different driver developers to create a system of interoperable and interconnectable drivers as long as particular sets are implemented. Furthermore, the specification can define mandatory properties, methods, and events that must be supported as well as optional properties, methods, and events that can be implemented depending on the driver functions and advanced capabilities. In addition to the basic minimum commonality required, driver developers may incorporate additional functionality by defining their own sets and assigning them a GUID. By being able to enumerate supported functionality (i.e., make queries for supported GUIDs and RUIDs), a caller, such as a third party controlling agent, can adjust expectations or make appropriate compensation depending on the capabilities of the underlying filters.
In order to create a buffer allocator instance, a create I/O operation is again used specifying the particular connection pin instance by its handle as parent will return another handle representing the buffer allocator. This buffer allocator handle is then placed in a property found on a source connection pin instance so that the filter knows to transfer data to the new buffer managed by the indicated buffer allocator utilizing appropriate stream I/O operations.
These and other objects and features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.